The present invention relates to a bit counter stage, particularly for memories. More particularly, the invention relates to a bit counter stage with the associated external address loading path for memories and the like.
It is known that counters are used in a wide variety of situations, one of the most important being the counting of memory addresses.
It is known that a counter is provided by means of a plurality of cascade-connected counter stages, each stage being meant to count one of the bits of, for example, a memory address.
The sum of two binary numbers generates a carry value which must propagate along the counter, through the various stages of the counter, in order to obtain a correct sum.
The carry calculation time is the fact that limits the operating frequency of a counter.
Execution of the carry operation, i.e., its writing time, is the least time-consuming operation; carry generation instead limits and penalizes the operating frequency of said counter.
Owing to the need to increase ever more the operating frequency of the counter and therefore to reduce the period of its operation, in conventional counters in which said period is divided evenly between the carry generation step and the carry calculation step the carry generation step, which is the most penalizing one, may not have enough time available for its execution, whereas the carry execution step has an assuredly excessive amount of time available.
Moreover, any counter has a loading system which allows to load the initial configuration from outside. It is normally believed that loading management performed by means of an ALE control signal is generally free from reliability problems, but in actual fact there are severe difficulties due to the capability to distribute the current count produced by the counter. In conventional counters, the ALE (address latch enable) address in fact can generate a false count in the counter if the ALE signal is "dirty", i.e., accidental, or if it is not an actual ALE signal.
In this case, the configuration assumed in the counter is destroyed in favor of a configuration which is set externally and the count resumes from the new loading instead of from the current calculation. This should not occur.
This situation becomes severe if the counter is directly interfaced with input structures, and in this case the problems involved in preventing possible false updates of the counter become very important.